home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2807 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.4 KB  |  90 lines
  1. Path: news.ssnet.com!not-for-mail
  2. From: helie@ssnet.com (Ray Helie)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Virtual Members: Difficult Question
  5. Date: 19 Jan 1996 14:53:39 -0500
  6. Organization: SSNet, Inc.
  7. Message-ID: <4doss3$b1i@marlin.ssnet.com>
  8. References: <4dmha6$80c@marlin.ssnet.com> <4doof9$hom@charnel.ecst.csuchico.edu>
  9. NNTP-Posting-Host: marlin.ssnet.com
  10.  
  11. James Robert McElroy <mcelroy@ecst.csuchico.edu> wrote:
  12. - A general comment about your code:
  13. - 
  14. - You are casting the wrong way in the inheritance hierarchy.
  15. - This is guaranteed to blow up at some point, often unpredic-
  16. - tably.  Some times it will work, some times it won't (similar
  17. - to driving the wrong way down a one-way street).
  18. - 
  19. - Look at it this way:  in terms of physical space taken up by
  20. - a class object, a base class object will always take up less room than 
  21. - a derived class object, right?  Now, if you tell a base class object it is
  22. - actually a derived class object (via the cast) the pointer now thinks
  23. - it has more room in memory than it actually does.  
  24.  
  25. Unless the base class object was *itself* gotten by casting it 
  26. from the larger derived object, which is what *I've* done..
  27. I understand what you're saying, but when the memory at that
  28. object's location was originally allocated, it /was/ of the
  29. larger size (the derived object's size)-- look at the sample
  30. code again, I think I stated it correctly.
  31.  
  32.  
  33. - Look at it this way -- would the following code cause  problems?
  34. - 
  35. - int foo;
  36. - long * fubar = (long*)&foo;
  37. - *fubar = 10;        // gee, no problem here
  38. - *fubar = 32468551;  // uh oh.  Seems to crash.  Don't know why!
  39. - 
  40. - Yup.  Similar to what you are experiencing. 
  41.  
  42.  
  43. You are right and I'm well aware of /that/ problem (who isn't?)-- your 
  44. example is not a match of my example.  Using what you just wrote, /this/ 
  45. is my problem (although not using objects, this example seems pointless):
  46.  
  47. int   foo;
  48. long  foobar;
  49. int*  pInt;
  50. long* pLong
  51.  
  52. foobar = 1234567;
  53. pInt = &foobar; // pointless, but it will not stop you
  54. // right now I have a pointer to a smaller object (pInt), but the
  55. // larger object's data (pLong) should still be there,
  56. // so the following line:
  57. pLong = pInt;
  58. // followed by
  59. printf ("%l",*pLine);  // should print out 1234567
  60. // should still work.  and that's what I'm doing in my program.
  61. // the memory for the biggest variable (ie., the derived class)
  62. // is already allocated, even though later I cast the pointer
  63. // to a smaller object (the base class), and it thinks there's
  64. // less memory there.  but there *is* more memory there
  65. // due to the *initial* definition.
  66.  
  67. // and now what fails for me is:
  68. char* pChar;
  69. pChar = pInt; // again pointless
  70. pLong = pChar;
  71. *pLong = 11223344;
  72. printf ("%l",*pLine); // this line fails, trying to show
  73. // similar problem I'm having.. it should have printed out
  74. // 11223344, but instead dies.
  75.  
  76. In a nutshell, I declared object of derived size, cast to the
  77. base, cast again to a parent class of base, cast back to base,
  78. tried to write a derived amount of data to the base class (as if
  79. it was an array of characters, starting at the object's address,
  80. which is the same way I wrote the information to begin with), and
  81. it dies on me when I do a virtual function call.  The derived amount of 
  82. space is there -- that's what I started with.  
  83.  
  84. So I don't think you understand my question, because I understand
  85. what you're saying, you are right under the circumstances you
  86. described, but I think you got the circumstances wrong...?
  87.  
  88.  
  89. If anyone else can help, I'd appreciate it.  :)
  90.